home *** CD-ROM | disk | FTP | other *** search
- Path: digex.net!not-for-mail
- From: jdc@access2.digex.net (John Cochran)
- Newsgroups: comp.std.c
- Subject: Re: Circular buffering for FILEs? Why not?
- Date: 1 Jan 1996 18:20:46 -0500
- Organization: Express Access Online Communications, Greenbelt, MD USA
- Message-ID: <4c9q8e$63i@access2.digex.net>
- References: <4c9i65$3b6@segfault.monkeys.com>
- NNTP-Posting-Host: access2.digex.net
-
- In article <4c9i65$3b6@segfault.monkeys.com>,
- Ronald F. Guilmette <rfg@monkeys.com> wrote:
- >I have a question about the traditional implementation of buffered FILEs.
- >
- >(My apologies to readers of comp.std.c. I know this isn't a question
- >which relates directly to the text of the C standard, but I do need to
- >put the question to people who are well versed in the details of C imple-
- >mentations, and comp.std.c is one likely place to find such people.)
- >
- >Traditional implementations of getc and putc look pretty much as follows:
- >
- >----------------------------------------------------------------------------
- >#define getc(p) (--(p)->_cnt < 0 ? __filbuf(p) : (int)*(p)->_ptr++)
- >#define putc(x, p) (--(p)->_cnt < 0 ? __flsbuf((unsigned char) (x), (p)) \
- > : (int)(*(p)->_ptr++ = (x)))
- >----------------------------------------------------------------------------
- >
- >The important point to note here is each of these macros causes the
- >``file pointer'' (_ptr) to be incremented... in a very simple-minded
- >fashion... whenever a character is taken from, or added to the FILE's
- >buffer (respectively).
- >
- >From this fact I deduce that traditional implementations of the entire
- >stdio set of functions _do not_ treat FILE buffers as so-called ``circular
- >buffers'' but rather treat them a mere linear buffers.
- >
- >My question is just this... Why?
- >
- >Given that traditional implementations of the FILE structure include a
- >``_cnt'' field, it seems to me that it would have been possible... albeit
- >at a slight cost... to treat FILE buffers as circular buffers, wraping
- >the value of _ptr back to the physical beginning of the buffer each time
- >it was seen to have passed the physical end of the buffer. But it seems
- >that nobody does this. Why not?
-
- Why bother?
-
- The purpose of a buffered file is to improve performance by reducing the number
- of physical I/O operations.
-
- Lets look at the 2 major cases, input and output.
-
- If the buffered file is used for input. You first fill the buffer. Then as
- long as the buffer isn't empty, you return bytes from the buffer. When the
- buffer finally empties, you fill it again. Notice that you never perform a
- physical I/O on the buffer unless it is empty. Implimenting the buffer as
- a circular buffer wouldn't improve performance and would just make it more
- complex.
-
- Now if the file is being used for output. You start with an empty buffer. You
- proceed to fill the buffer. When ever the buffer fills, you flush it to the
- physical device. Once again, the only physical operation is to flush the entire
- contents of the buffer. When you write anything from the buffer, you write the
- entire contents of the buffer. So a circular buffer wouldn't gain you anything
- except more complexity.
-
- Hope this helps.
-
-